A resource is binary data or non binary data, e.g., a text file. In Windows NT.RTM. and all other O/S of the Windows.RTM. family, resources are binary data Resource data can reside in the executable file of an application, so the executable file is a binary file with code and resource data in it. Processes defined by the code can use the resources in their own binary executable files or other executable files. Resources used by such processes may also reside in resource-only files, for example, resource-only dynamic link libraries (DLLS). A resource may be either standard or user-defined. The data in a standard resource describes an icon, cursor, menu, dialog box, bitmap, enhanced metafile, font, accelerator table, message-table entry, string-table entry, or version. A user-defined resource contains any data required by a specific application. The resources required by operating system processes may be handled in various different ways. Many of these resources include words, symbols, formatting data, etc. that are language-specific. Usually, a particular language is determined by the operating system installation package chosen by the user. If the language of the software is English, only the English language-specific resources will be installed with the operating system. This is convenient because of the large quantity of language-specific resources that would have to be copied on the hard-disk to cover all languages.
Providing a single language for the operating system to support is also convenient because it allows resources to be efficiently loaded and unloaded into and from memory as the need arises. Far too many resources exist for all to reside in memory at all times. To manage the loading and unloading of resources so that resources do not unnecessarily occupy memory when not required, the code that generates the processes requiring the resources and the resources peculiar to the process may be incorporated in the same binary files. When a process is invoked, a binary file containing the code for the process, and the attendant resources, may be loaded into memory or otherwise made accessible to the process. When the process is terminated, the resource and code sections of such a file are unloaded from memory or otherwise made in-accessible. These binary files can be executable programs, dynamic link libraries (DLLs), device drivers, etc. If they were bloated with all the alternative language resources, an excessive amount of memory would be required.
An example of how one operating system handles such resources is as follows. First, a resource finder, an operating system function, is employed to create a handle to the specified resource's info block. A process requiring a resource sends the finder a resource module handle and the resource name, type, and optionally, a language ID. The latter specifies a language specific resource in the resources defined by the resource module handle. The finder returns a handle to the specified resource's info block and the process can call a resource loader to place the resource in memory. The process gives the resource handle and the resource module handle to the resource loader, which places the resource in memory and returns a handle to the memory block containing the resource. The resource is then available to the process. The operating system may then use other devices to free the memory after the process loading it into memory no longer needs it, is terminated, or if other conditions require it.
The above is only one type of resource access facility in an example operating system. Other mechanisms may make resources available in other ways, such as by placing text messages in an output buffer, immediately loading and returning a handle to resource data in a single function call, etc. The common feature of these mechanisms is that they find a resource either in memory or in a disk file or other storage system and make the resource available to the process that requires it. This may involve loading a file from disk into memory or just providing access to the resource by providing a handle or some other device. The file (device, or channel) containing the resource may be in the same file as the code defining the requesting process or another file. The other file could contain code or be a resource-only file. A process may not need explicitly to unload a resource it no longer needs.
With the low cost of disk storage, it may be desirable in some instances for the same installation of an operating system to provide, transparently to the user, appropriate resources for a number of languages. This would allow users of various tongues to share the same computer. The user would log on, select a desired language, and use the computer, thereafter seeing all resource-based operating system features in the chosen language. However, for an operating system built around the above resource management regimes, the options available to modify the operating system to accommodate selectable languages appear quite problematic, as discussed below.
To provide multilingual support, one option might be to provide a different set of binary files for each language. Considering there might be on the order of a thousand binary files containing language-specific resources in an complex operating system and that it might be desired to support many different languages, the number of binary files to be installed would be large indeed. In addition to the labor required to provide for the selection of a language by the user, the redundancy in the resulting mass of files would be tremendous because all language-non-specific resources would be duplicated for each language supported. Not only would the language-non-specific resource require duplication, but also all the code sections.
Another option might be to install the operating system binary files anew, each time a new user requiring a different language logged on. This option is unattractive because it would take a great deal of time.
Still another option might be to provide the different language-specific resources in each binary file. This would eliminate the redundancy of the first option since each binary file would only add language-specific resources. However, this option would require recoding of each binary file, so it also is not an elegant option. Something similar to this is currently done on a very limited basis. Some binary files contain alternate resources, each being preferred depending on the language or country of the user. The code sections of these binary files define processes that address a different resource based on a "guess" as to the preferred language of resource. This guess is made based on the settings of some system parameter, for example, which date format has been selected. So, for example, if a Russian style of date is selected, the resources tagged as Russian might be loaded.
There is at least one type of operating system that now provides for language selection on a limited basis. This operating system provides separate text files for each language. When a process requires a text file resource in a particular language, the operating system addresses the appropriate file. The user can select his default language of choice through a system variable.
As mentioned briefly, at least one current operating system (Windows.RTM.) provides some support for the creation of language-specific libraries, for example text messages. A system variable is defined indicating the locale (Note, the locale of a system is not a language setting. Locale is a mixture of language and location) of the operating system installation and this variable can be used by the applications running on the operating system to format messages specifically for the current language. This requires, however, that the process (the application) identify precisely the appropriate language resource and where it is located. As a model for conversion it would entail extensive recoding.
None of the prior art operating system regimes offers a model suggesting how to provide multilingual support by the operating system in a very automatic way. Also, none suggests means of preserving some of the inherent economies of binary files with code and resource sections in the same file. The simple transformations suggested above to provide the desired functionality appear to be unduly expensive and/or bulky in terms of the redundant data required. Any conversion that is readily implemented would likely have to be a system that departs significantly from any of the prior art systems.
Referring to FIG. 1, in a common operation in a prior art operating system, a binary file 20 is loaded. The binary file 20 contains a code section 10 and a resource section 30 and may be any file unit of the operating system or one supplied by a third party. For example, the binary file 20 could be an executable binary, a dynamic link library (DLL), or a device driver. The resource section 30 may contain some of the resources used by the code section, particularly those resources peculiar to the requirements of the processes generated by the code section 10 and which may be unloaded from memory when the processes defined in the code section 10 are no longer required. In other words, the resources 30 are those that may be required by processes encoded in the code section 10 and once those processes are terminated, there is no longer any need to maintain the resources contained in resource section 30 in memory. For example, the binary file 10 could be a core resource or an application that is supplied with the operating system such as a stripped-down text editor. For the editor, for example, when the user terminates the editor program, the resources required by this text editor would no longer be required. The binary file 20, including code 10 and resources 30, would be removed from memory. Of course, the code section 10 could use other resources from other files and may also use other processes as well.
Referring to FIG. 2, resources 85 and the code 55 that uses it may also be located in separate respective files 25 and 22. For example, the resource 85 addressed by an application 55 defined in a piece of code 50 may be contained in a resource-only DLL or a separate file 25 that contains code 70 and resources 60. The application 55 may reside in a file that also contains resources 40. Another operating system device may be used to find the file by resource type and name. The management (loading and unloading) of the resources may be handled by the resource loader.
Referring to FIG. 3, resources are addressed by a process 110 using a resource loader 130 and a resource finder 135. The resource loader is an operating system facility that provides access to a resource datum 125 given a resource module handle and resource handle. The resource module handle, which indicates where the resource datum, specified by the resource name, can be found, is created by the resource finder. The resource name, type, and a language (the latter is optional) are provided to the resource finder 135 which returns a resource module handle. If the resource is in a module other than the one that generated the calling process, the handle of that module must be provided to the resource finder as well. The resource type may specify for example a bitmap, an animated cursor, a font resource, a menu resource, a string-table entry, etc.
The resource loader loads the specified resource into memory. It requires a resource module handle and resource handle. The resource module handle is the module whose executable file contains the resource. The resource handle identifies the resource to be loaded. The resource loader 130 returns a handle to the memory block containing the data associated with the resource. The description shown in FIG. 3 is consistent with either of the situations shown in FIG. 1 or FIG. 2. Note that examples of the above functions are defined in documentation relating to the Windows.RTM. APIs FindResource and LoadResource. Note also that the resource may be loaded in a prior operation as well as part of a call for a resource as described above. For example in the Windows.RTM. operating system, a call to LoadLibrary could result in the loading of a module into memory.
Referring to FIG. 4, a generalized schematic of how resources may be addressed in an operating system is shown. A resource handler 230 is used by a process 210 to obtain access to a resource datum 220. The resource handler 230 may consist of several different devices provided by the operating system, for example as discussed with reference to FIG. 3. The process identifies the requested resource to the handler 230 and may tell the handler where the resource can be found, such as a file name, identifier of a module 250 or some other information. The resource handler 230 may need to load the resource 220, possibly included in a module 250, into memory or some other means for making the data accessible 240 providing access to the process 210. The process 210 is given a handle, address, pointer, etc. to access the resource 220. The important features of the process described by FIG. 4 are that the process identifies the resource required and the operating system provides the process with access to that resource. The resource may reside on a disk, on another computer connected by a network, provided through a communications port or any other mechanism for transferring data to a process on a computer. The operating system may, as part of the request, transfer the resource to a different medium, say, for example, from disk to memory, before access to the resource by the process is possible.